This disclosure relates to debugging circuitry on an integrated circuit chip. The disclosure is particularly relevant to functionally testing circuitry on an operational integrated circuit chip.
In the past, an embedded system which had multiple core devices (processors, memories etc.) would have been incorporated onto a Printed Circuit Board (PCB) and connected on the PCB via buses. Traffic in the embedded system was conveyed over these buses. This arrangement was convenient for debugging the core devices, because debugging tools such as oscilloscopes and logic analyzers could be attached to the PCB's buses allowing direct access to the core devices.
Market demand for smaller products coupled with advances in semiconductor technology has led to the development of System-on-Chip (SoC) devices. In a SoC, the multiple core devices of an embedded system are integrated onto a single chip. In a SoC, the traffic in the embedded system is conveyed over internal buses, thus connection of debugging tools directly to the system bus is no longer possible. The resulting reduced access coupled with an increasing quantity of data being transported around the chip (due to developments of SoC technology leading to integration of multiple processing cores and higher internal clocking frequencies), has reduced the ability of external debugging tools to find and solve bugs within the system in the timescales demanded by the industry.
These days, two types of testing are commonly performed to identify problems with a SoC device prior to it being placed on the market. The first type of test is known as Design for Test (DfT). DfT is implemented on a chip which is operating in a dedicated test mode. This dedicated test mode is mutually exclusive to the end-use functional mode which the chip operates in in the final application product. The purpose of the DfT is to determine if the chip hardware has been manufactured correctly, and to identify any problems if it has not. DfT does not, and is not capable of, testing the operational functionality of the chip. In other words, DfT does not, and is not capable of, testing the functionality of the chip whilst the chip is operating in its end-use functional mode.
The second type of test is known as functional testing. Due to the problems outlined above, functional testing of an embedded system is generally done in a simulation environment. Typically, a validation plan is generated which itemises the functions of the SoC that are to be tested. Each function is simulated and functional coverage software is used to record the outcome. The outcome is then reviewed, and if as expected, that function is determined to have been successfully validated. A problem with simulation environments for hardware circuits is that they are extremely slow compared to the SoC hardware operating in normal conditions (about 1/10,000,000). Consequently, functional testing of even basic functions takes a very long time to run, often equivalent to several years' time if on a single processor. Chip designs comprise many subassemblies that may be validated independently before being assembled into a complete chip. Thorough validation of a complete SoC design using a simulator is thus impractical. Hardware emulators can be used, which are faster and have a higher capacity than simulators making them more suitable for validating complete chip designs. But hardware emulators are still significantly slower than the SoC hardware operating in normal conditions (about 1/1000). They are also very costly, and thus a scarce resource that is rationed even if available. A further option is to perform the validation on a Field Programmable Gate Array (FPGA) device. An application with a single FPGA is significantly quicker than a simulator or emulator, but still slower than the SoC hardware operating in normal conditions (about 1/10). When the design is spread over several FPGA devices the speed drops to those comparable with a hardware emulator (about 1/1000). It is also very time consuming to port a SoC design to a FPGA, and difficult to determine the functional coverage metrics.
These limitations coupled with the cost and time pressures of the industry result in very limited functional testing of complete chip designs, and hence very limited validation being undertaken on the embedded systems prior to them being released to the market. Consequently, once a SoC is released to the market, and being operated at full-speed under normal conditions, bugs surface which were not detected during the validation process. Thus, there is a need for improved functional testing of SoC devices.